IBIS Macromodel Task Group Meeting date: 2 December 2008 Members (asterisk for those attending): Ambrish Varma, Cadence Design Systems Anders Ekholm, Ericsson * Arpad Muranyi, Mentor Graphics Corp. Barry Katz, SiSoft * Bob Ross, Teraspeed Consulting Group Brad Brim, Sigrity Brad Griffin, Cadence Design Systems * David Banas, Xilinx Donald Telian, consultant Doug White, Cisco Systems Essaid Bensoudane, ST Microelectronics Fangyi Rao, Agilent Ganesh Narayanaswamy, ST Micro Gang Kang, Sigrity Hemant Shah, Cadence Design Systems * Ian Dodd, Agilent Joe Abler, IBM * John Angulo, Mentor Graphics John Shields, Mentor Graphics Ken Willis, Cadence Design Systems Kumar Lance Wang, Cadence Design Systems Luis Boluna, Cisco Systems * Michael Mirmak, Intel Corp. Mike LaBonte, Cisco Systems Mike Steinberger, SiSoft Mustansir Fanaswalla, Xilinx Patrick O'Halloran, Tiburon Design Automation Paul Fernando, NCSU * Pavani Jella, TI * Radek Biernacki, Agilent (EESof) * Randy Wolff, Micron Technology Ray Comeau, Cadence Design Systems Richard Mellitz, Intel Richard Ward, Texas Instruments Sam Chitwood, Sigrity Sanjeev Gupta, Agilent Shangli Wu, Cadence Design Systems Sid Singh, Extreme Networks Stephen Scearce, Cisco Systems Steve Pytel, Ansoft Syed Huq, Cisco Systems Syed Sadeghi, ST Micro * Terry Jernberg, Cadence Design Systems Todd Westerhoff, SiSoft Vikas Gupta, Xilinx Vuk Borich, Agilent Walter Katz, SiSoft Zhen Mu, Cadence Design Systems ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - No one declared a patent. ------------- Review of ARs: - Michael M: Confirm with Synopsys whether "used by permission" can be used as the official indicator on relevant documents. - Michael wrote another email to Synopsys with no response back yet - Arpad: Write parameter passing syntax proposal (BIRD draft) for *-AMS models in IBIS that is consistent with the parameter passing syntax of the AMI models - TBD - TBD: Propose a parameter passing syntax for the SPICE - [External ...] also? - TBD - Arpad: Review the documentation (annotation) in the macro libraries. - Deferred until a demand arises or we have nothing else to do ------------- New Discussion: Brain storming session on what the majorly overhauled IBIS specification should look like. Bob: Initially was reluctant to overhauling IBIS - Arpad: Clarify your statement from the last set of minutes about opposing a major change for C_comp - Bob: If a new feature requires restructuring fundamental structures of IBIS, making old versions of IBIS incompatible, he is opposed to this - Arpad: We should focus on the idea of starting over with a new IBIS spec, maybe with a different name - Bob: Ok with this idea. - Lots of companies with current IBIS solutions will maintain support for current IBIS. New IBIS would need link to old IBIS. Michael: It is helpful to clarify assumptions of things we like about existing IBIS and what we need a new IBIS for. - Arpad: What would be the general feel of new IBIS? - I-V and V-t curves still or equations? Michael: We must look at a higher level, what is needed? - Pin information, measurement info, modeling info, packaging info? - Arpad: Behavioral models are useful for circuit designers, but need to cover the level of entire systems - John: There are three issues: assigning models to the system, how do you simulate them and how to interpret the simulation results - Michael: Agrees with John. - One needs to assign a model, but represent models of devices and whole systems. - Solution must be truly universal, work close to the same in multiple tools. - Randy: Need to model buffers separately from packages and system level models that need netlists Arpad: What is IBIS lacking right now? - Michael: At a low level: not enough controllability - example is coefficients for equalization. Data is too hard to extract. - At a high level: three major assumptions in current spec that aren't appropriate anymore: - typ/min/max concept, with three corner format defining an envelope - having waveform correlation with exact overlays is not needed in SerDes - post layout is not as strong an interest to many people - IBIS is not setup well for pre-layout simulation. - Arpad: Tables make it difficult to deviate away from corner concept, while equations are better suited to allowing more control over PVT variation. Arpad: Is this the right group of people to do the work, or should we just make the list in this group and form a new subcommittee? - Michael: Sending this to the Open Forum will end up back in the same group to implement. Arpad: Let's form a list of what we need. - Pavani: Most models at TI are differential. It is inconvenient correlating to SPICE. Most buffers they have been able to model ok. - Several power supplies on a single buffer are difficult to model. - Customers currently don't express interest in accuracy, ok with IBIS models. - Arpad: Why is there still a concept of IBIS being inaccurate? - Pavani: Due to limitations such as the difficulty of modeling a buffer with several pullup structures to different power supplies. - Arpad: There are limited keywords now to describe this situation. Pavani: IBIS serves its purpose for her customers. - Arpad: What is its purpose? - Bob: New IBIS could embrace existing IBIS applications but expand to include others. - New IBIS could be directed towards some advanced technologies, but may be a buffer only spec. - Other formats could handle package, etc. - Would like to let IBIS remain supported forever for low end technology. Arpad: If we come up with a new IBIS, it feels like it may end up looking like an AMS language. Is it worthwhile to come up with a new language from scratch when there are languages existing? - Radek: IBIS describes acceptable limits as well as buffers. - Moving forward need eye masks, etc. to address the measurement side while still focusing on the behavior side. - Arpad: You can not add eye diagram specs without a new keyword currently. In AMS, you can define this easily. - Michael: Whatever we decide on has to be easy to use and easy to extract. - It is no longer IBIS vs SPICE, behavioral has won, but IBIS is losing as the behavioral choice. - There are great advantages with IBIS like measurement point that are easily described in the model and left up to the tool to measure. - May be easy to extract new data in a company with an AMS type flow, but other companies will have difficulty extracting new models. Arpad: The problem with AMS is it is unfamiliar, right? - Michael: It is hard to use. - Arpad: Yes, VHDL-AMS is hard. But do we benefit from studying these languages? - Take the best of everything and make a new language. - Bob: Need to look at linking models such as making executables. - AMS is just not part of the design stream for most of the tools. - Mathcad or C may be more appropriate. - If using a language based format, how do you turn a silicon model into the right equations? Arpad: SPICE is familiar, maybe start with a SPICE-like syntax but expand it. Would this be reasonable? - Michael: Does this address our list of needs? - Arpad: A new SPICE must be expanded to cover the list such as to add pin lists or measurement specs. - Bob: We just started with a subset of a SPICE language. How to now extend it? - Arpad: Starting with SPICE-like syntax might just be best because it is familiar. - Bob: You must understand how the model will be processed. - You must have motivation for EDA vendors to support it because it does what we need it to. - Radek: IBIS allowed you to match simulations to measurements, it maps components, and it provides measurements. - We must follow a path of standardization. - You need to be able to run batch simulations, so this requires many standardized parameters, temp vs. temperature, Farenheit vs. Celcius. Arpad: We will continue this topic next week. He will come up with other questions. Next meeting: 09 December 2008 12:00pm PT -----------